Create immutable action version on tag push #3264
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR modernizes the immutable action versioning workflow by changing its trigger from release publication events to tag push events. The change simplifies the workflow by eliminating the need for runtime checks to distinguish CodeQL Action releases from CLI bundle releases, as the tag pattern filter now handles this distinction at the workflow trigger level.
Key Changes
- Changed workflow trigger from
release.publishedtopush.tagswith version tag pattern filtering - Removed the conditional release name validation step that checked if releases were for the CodeQL Action
- Simplified step names and removed conditional execution guards
| push: | ||
| tags: | ||
| # Match version tags, but not the major version tags. | ||
| - 'v[0-9]+.**' |
There was a problem hiding this comment.
The tag pattern 'v[0-9]+.' is incorrect glob syntax. The double asterisk '' is not a valid glob pattern for matching version numbers. This should be 'v[0-9]+.*' (single asterisk) to match tags like 'v3.29.9', or 'v[0-9]+.[0-9]+.[0-9]+' to explicitly match semantic version tags.
| - 'v[0-9]+.**' | |
| - 'v[0-9]+.*' |
There was a problem hiding this comment.
This PR changes the workflow that creates the immutable releases to trigger on tags getting pushed (only specific CodeQL Action version tags, not major version tags or CLI bundle tags), rather than releases being published.
Risk assessment
For internal use only. Please select the risk level of this change:
Which use cases does this change impact?
Release CI.
How did/will you validate this change?
If something goes wrong after this change is released, what are the mitigation and rollback strategies?
If this results in a problem during the next release, we could manually run the workflow later for the relevant tag.
How will you know if something goes wrong after this change is released?
We will see during the next release.
Merge / deployment checklist